I'm not sure what the is_on_curve() here really does. We reduce the y-coordinate and derive the x-coordinate, so I believe we always end up with a point that is on the curve.

Additionally, why do we require torsion-freeness on points in the first place? I think this should be optional and not enforced by the default decompress() function.

I'm not sure what the is_on_curve() here really does. We reduce the y-coordinate and derive the x-coordinate, so I believe we always end up with a point that is on the curve.

Yes, ideally points that aren't on the curve are unrepresentable, because the constructors be it via decompression or validating that a given set of affine coordinates are valid solutions to the curve equation always ensure a valid curve point.

Ideally if such a function exists you shouldn't need to make an invalid curve point first in order to check it! Rather the check can be implemented as a constructor which returns a point type only if the coordinates are valid.

I did go ahead and remove both checks, is_on_curve() and is_torsion_free(), in #1336.

Re: constructors that check affine coordinates, here's an issue for that for curve25519-dalek if you'd like to coordinate on APIs: dalek-cryptography/curve25519-dalek#817